Computer programs may be written to allow different portions of the program to be executed concurrently using threads or another suitable concurrent execution mechanism. In order to execute different portions of the program concurrently, the computer system or the program typically includes some mechanism to manage the memory accesses of the different portions to ensure that the parts access common memory locations in the desired order.
Transactional memory systems allow programmers to designate transactions in a program that may be executed as if the transactions are executing in isolation (i.e., independently of other transactions and other non-transactional sequences of instructions in the program). Transactional memory systems manage the memory accesses of transactions by executing the transactions in such a way that the effects of the transaction may be rolled back or undone if two or more transactions attempt to access the same memory location in a conflicting manner. Transactional memory systems may be implemented using hardware and/or software components.
Transactional memory systems, such as software transactional memory (STM) systems, often have limitations on the types of programming scenarios that are supported. For example, STM systems do not typically support the use of thread local memory in transactions, the interoperation between transactional and traditional locks, the use of static class initializers and modular initializers, the use of software lock elision inside transactions, and the use of a customized abstract concurrency control. While developers of STM systems may be able to implement separate solutions for each of the above scenarios as well as other scenarios, separate solutions may be costly and may result in an undesirable architecture of an STM system. An STM system with a unified and efficient solution that allows a wide range of programming scenarios to be supported would be desirable.